!pr1
Convert Two Decimal Digits to Binary.......Bob Sander-Cederlof

I have recently been running into more and more uses for the decimal mode in the 6502.  In the decimal mode, each byte contains a value from 0 to 99, with the ten's digit in the left nybble and the units digit in the right nybble.

The 6502 has built-in capability to add and subtract values in this format, with automatic carry when a nybble exceeds 9.  If you have been following my series on 18-digit arithmetic, you have seen a lot of examples of its use.

A frequent problem that arises is conversion between the decimal form and the binary form of a number.  I suppose I have written ten million different programs to do this kind of conversion, on at least a thousand different kinds of computers!  (Ever notice that my exaggerations are always in decimal?)

For a small (byte-size) example, suppose a byte contains two decimal digits ($00-$99) and you want to convert it to binary ($00-$63).  The first step is to separate the two digits into two different variables.  The the ten's digit should be multiplied by ten, and the unit's digit added.

Lines 1390-1510 in the listing perform these steps, but there are a few tricks.  Lines 1410-1420 strip out the unit's digit and save it in LOW, and lines 1440-1450 save the high digit in HIGH.  Notice that I did not shift the high digit down, so it is really the ten's digit times 16 (call it "tens*16").

Lines 1460-1500 multiply the tens*16 by 10/16.  Then line 1500 adds the unit's digit.

The program in lines 1010-1190 is a test driver, which calls the DEC.HEX.2 routine 100 times with successive values in the A-register between $00 and $99.  DEC.HEX.2 returns with the converted value ($00-$63 in the A-register, and the test driver prints out the value.  If everything is okay, the hexadecimal numbers from $00 through $63 will be displayed.

DEC.HEX.2 as written takes 18 bytes plus two variables in page zero.  If the variables are not in page zero, the program will take an additional four bytes.

A faster program which takes only a few more bytes, and does not use any variables in RAM other than the stack, is shown in lines 1200-1340.  Lines 1220-1260 convert the ten's digit into an index 0-9 in the X-register.  Line 1270 retrieves the original number from the stack.  Lines 1290-1300 add a value from the table, indexed by the ten's digit, giving a total which is the converted number.

The values in the table consist of one byte each, having selected so that they subtract out the hexadecimal value of the ten's digit and add back the value of that digit-times-ten in binary.  For example, if the original number was $58 (meaning decimal 58 in BCD storage format), we will add the value $E2 (which is 50-$50).  $58+$E2 = $3A, which is the correct hexadecimal conversion.

I recently worked on a consulting project which included a lot of mixed decimal and hexadecimal calculations.  The project was implemented on a 6511 chip, which has only 192 bytes of RAM.  That is total, including the stack!  We also had 4096 bytes of EPROM.  The system operates in a real-time mode with relatively high-speed interrupts occurring.  With these constraints, every routine had to be written to use the minimum amount of RAM and to be as fast as possible.  A few extra bytes of code would be all right, because 4096 bytes of EPROM was more than enough.  In situations like this, programs like the one in lines 1200-1300 come in real handy.
